Styleable transitions

ABSTRACT

The described technology is directed towards determining the rendering of user interface (UI) elements, referred to as views, based upon styleable transitions between possible states of a view. Transitions may include animation, such as to smoothly enter a view into or exit a view out of a scene over a number of rendering frames. Transitions also may be applied to view state changes related to a UI element, such as to indicate hovered over, focused, listening (for speech), selected and/or pressed. View state changes also may be animated.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. provisional patentapplication Ser. No. 62/046,102, filed Sep. 4, 2014, the entirety ofwhich is incorporated herein by reference.

BACKGROUND

A user interface (UI) of a computer program, to be considered favorablyby end users, needs to be appealing, straightforward to use andconsistent in its operation. One of the ways to make a UIstraightforward to use is by using various mechanisms to guide the userin knowing where he or she is operating with respect to the UI. Atypical UI example is to highlight the currently focused UI element, sothat the user knows that further interaction with that element (e.g., aclick, tap, double-click, typing the “Enter” keyboard key and so on)will cause some action related to that particular element to be taken.

In certain situations, the sudden change of an element from one UI stateto another can be less than appealing. For example, consider that a UIelement that receives focus has its position changed so that it isindented relative to non-focused elements. A sudden jump to the newindented position (possibly in conjunction a jump back by a previouslyfocused element so as to no longer be indented) can seem unnatural andvisually unappealing.

SUMMARY

This Summary is provided to introduce a selection of representativeconcepts in a simplified form that are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used in any way that would limit the scope of the claimedsubject matter.

Briefly, the technology described herein is directed towards stylizedtransitions that determine how transitions between user interface (UI)states are rendered. Stylized transitions allow a program developer tocontrol transitions between UI states. This may include animating thetransition, to provide effects such as smooth entering and exiting of aUI element. This also may include repositioning, resizing, reorienting,changing color, changing opacity, and so on, each of which also may beanimated.

Other advantages may become apparent from the following detaileddescription when taken in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The technology described herein is illustrated by way of example and notlimited in the accompanying figures in which like reference numeralsindicate similar elements and in which:

FIG. 1 is block diagram showing various example components forimplementing styleable transitions, according to one or more exampleimplementations.

FIG. 2A is a state diagram showing example presence states of a UIelement (view) and state changes between those presence states,according to one or more example implementations.

FIG. 2B is a representation of an example visual tree state showingviews in various states in the visual tree, along with a disconnectedview that is not in the visual tree, according to one or more exampleimplementations.

FIG. 3 is a representation of how a view may change states relative to ascene/parent view, according to one or more example implementations.

FIG. 4 is a representation of example possible view states, according toone or more example implementations.

FIGS. 5A-5F are example “snapshot” representations showing a viewchanging states over time, including being animated to enter a scene andlater exit the scene, according to one or more example implementations.

FIGS. 6A and 6B are example representations showing a view changing aview state to indicate a hovered condition, according to one or moreexample implementations.

FIGS. 7A and 7B are example representations showing a view changing viewstates to indicate a focus change, which may include animating views'position changes, according to one or more example implementations.

FIGS. 8A-8C are example representations showing a view changing viewstates to indicate a focus and pressed view state, a focused view state,change, which may include animating views' position changes, accordingto one or more example implementations.

FIG. 9 is a flow diagram showing example steps related to communicatinga view's presence state and/or view state information for styleabletransition rendering, according to one or more example implementations.

FIGS. 10 and 11 comprise a flow diagram showing example steps related toprocessing presence state and/or view state information, according toone or more example implementations.

FIG. 12 is a block diagram representing an example computing environmentinto which aspects of the subject matter described herein may beincorporated.

DETAILED DESCRIPTION

Various aspects of the technology described herein are generallydirected towards a user interface (UI) technology that provides theability to use stylized transitions between UI “presence” states.Example presence states related to state transitions includedisconnected, in which a view (a UI element) is not in a visual tree (atleast not yet), and connected, in which a view (a UI element) is in thevisual tree but is not visible to the user, that is, is not yet in thescene. Other transitioning-related states include entering, in which aview is being transitioned into the scene, and exiting, in which a viewis being transitioned out of the scene. Note that out of a scene may bealternatively referred to herein as “off screen,” and in a scene may bealternatively referred to herein as “on screen.”

Each view can be styled with a set of transitions, including transitionsrelated to the entering or exiting presence states. These transitionsare described as a desired state in which to be while in the givenpresence state. For example, a UI element may be styled to initially beoff-screen (e.g., to the left), but to be on-screen (moving to thecenter) in the entering state, and off-screen again (this time moving tothe right) in the exiting state. Transitions are applied immediately ifthe view is disconnected from the visual tree, so in the above example,the view is immediately created out of the scene, e.g., to the left ofit. However, upon entering the visual tree and transitioning to theentering presence state, the entering transition style is applied,whereby the view animates onto the screen (from the left) until itreaches its desired location in the center of the screen. When the stateis changed, e.g., the user leaves the page, the view transitions to theexiting presence state, whereby the UI element animates off-screen,e.g., moving from the center to the right until out of the scene. Theanimation may, for example, include starting and ending positions and ananimation time, so that the rendering position may be computed for eachrendering frame or the like.

It should be understood that any of the examples herein arenon-limiting. For instance, transitions related tomovement/repositioning animations of a UI element are exemplifiedherein, however animations are not related solely to movement, butinclude concepts such as changing size, color, orientation, opacity andso on. As one example, instead of transitioning an element from left toright when in the entering state, an element may have its opacitygradually changed so that a transparent element transitions into a solidelement, and when later in the exiting state, has its opacity graduallychanged back to fade away the element. Any transition effects may becombined, e.g., an entering view may be animated to grow as it is alsoanimated to move from off screen left to the center of the scene (e.g.,left to right), and upon exiting shrink as it moves out of the scene(e.g., from the center to off screen right).

Further, any of the logic and the like may be implemented in software,hardware or a combination thereof. Still further, an entertainment/gameconsole is one example computing environment, however any other suitablecomputer-based device such as a personal computer, tablet device, mobilecomputer device and the like may implement the technology describedherein.

As such, the technology described herein is not limited to anyparticular embodiments, aspects, concepts, structures, functionalitiesor examples described herein. Rather, any of the embodiments, aspects,concepts, structures, functionalities or examples described herein arenon-limiting, and the technology may be used in various ways thatprovide benefits and advantages in computing and user interface conceptsin general.

In one or more implementations, UI elements that are configured (e.g.,as objects) to participate in styleable transitions (alternativelyreferred to herein as views) may possess a presence state. Views areinitially in the “disconnected” (not in the visual tree) state, exceptfor the root view of the visual tree, which is initially in the“entering” state. As set forth above, other states include “connected,”in which the view is in the visual tree, but is not yet entering thescene, “entering,” in which the view is entering the scene and“exiting,” in which the view is exiting the scene.

When views become children of other views in the visual tree, theyinherit their parent's presence. Whenever a view's presence is updated,that presence is applied to its children in the visual tree. Thus, forexample, consider a UI element such as an item container with child UIelements such as interactive tiles. If that container is transitioned toenter into a scene, its children are likewise in the entering state.When a view is removed from the visual tree its presence reverts to the“disconnected” state (as well as any children).

FIG. 1 shows example components related to styleable transitions. InFIG. 1, a user interacts with a view 102 via user input 104. In one ormore implementations, an input manager 106 comprising an object handlesinput in the form of keyboard input, pointer (e.g., touch and/or mouse)input, speech input, gesture input and/or the like (includingnon-traditional input such as based on eye gaze detection, brain sensingand the like).

In general, the input manager 106 processes the user input 104 to theextent expected by the view 102 and provides corresponding events to theview 102, including state change events 108. For example, keyboardevents are provided to the view 102, any speech input and gesture inputmay be converted to commands that are sent to the view, and so on.

In this way, based upon user interaction, a view (and any child views)may change presences states. However, a view may not need directinteraction to change states; as is understood, for example, a view inthe connected state is not in the scene and thus cannot be interactedwith, yet transitions to the entering state as a result of some event.Such other state changes may be caused by user interaction with a parentview or child view, for example, and thus act as another type oftransition triggering event, as represented in FIG. 1 via blocks 110 and112. Timing is another such event that also may cause a view statechange, e.g., a “Home” page at program startup may have some of itselements transitioned into the Home page even without any userinteraction, a “Help” button may be animated into a scene if the userappears confused by not taking any action for awhile, and so on.

FIG. 2A is a state diagram showing states related to transitioningviews. Views are initially in the disconnected presence state 220,indicating that they are not yet connected (or are no longer connected)to the visual tree 230 (FIG. 2B). Upon being connected to the visualtree, a view will transition to the connected state 222. From there, aview may transition to the entering state 224 and from the enteringstate to the exiting state 226. From the exiting state 226, a view maytransition to the entering state again, or may become disconnected if itis removed from the visual tree.

In one or more implementations, no animations are performed when theview is not connected to the visual tree (or when it is connected butnot entered); (notwithstanding, a view in the connected state may beprepared and buffered for rendering, e.g., an image associated therewithpre-fetched from the network in advance of its display, which mayinclude some styling). In general, only the entering and exiting stateshave transitions that can be styled. Note that FIG. 2B has an “enteredview” state that is not related to any further transition, but ratherrefers to when a view has finished the “entering” animation and iswaiting for some further event that changes its presence state toexiting. Such a waiting state may be considered part of the enteringstate 224.

Presences states are alternatively shown in FIG. 3, where a scene 330(which may be a parent view) includes a child view (UI element) thattransitions from the disconnected state 332 a to the connected state 332b and then to the entering state 332 c. After an event, the child viewtransitions to the exiting state 332 d. From there, as represented bythe curved and dashed arrows, the child view may be returned to thedisconnected state 332 a or be returned to the entering state (possiblyanimated to re-enter from the opposite direction so as to appear to becoming back from where it exited).

Returning to FIG. 1, when a view state changes, the state change ishandled by a view state manager 114, e.g., comprising part of the view'slogic/code. In general, in addition to the typical input handlingmethods and rendering code, any view may participate in styleabletransitions by including a view state manager 114 as part of its logic.As can be readily appreciated, it is alternatively feasible to have aview communicate with an external view state manager.

The view state manager 114 tracks the current state 115 and also mayinclude a set of transitions 116 for the view's presence states, e.g.,information on what to do with respect to entering, exiting and soforth. Further, a parent view can specify a set of transitions to applyon its children (comprising child style overrides 117 that override anychild's styled transitions). This allows a container view to control howits children enter and exit, for example.

Note that a higher-level parent container can also contain a lower-levelparent container that has children and so on. The overrides from thehigher-level parent container may supersede those of the lower-levelparent container in the event of a conflict. However, it isalternatively feasible to only use the overrides of a direct parent.Still further, a mechanism that instructs the view state manager on whatto do on a container-by-container basis may be used, e.g., use thesettings of direct parent (container A) for transitioning the childrenof container A without any higher overwriting, overwrite any conflictingsettings of direct parent container C with those of a higher parent(container D) for transitioning the children of container C, and so on.

If a view does not specify a particular piece of information, e.g.,color, the view state manager can use information from a set of defaultstyles 120 so that, for example, the UI can maintain a certain themesuch as a color scheme without the developer having to program eachelement with all possible style properties. Note that default styles maybe inherited by a view object, in which event the default styles arealready present in the view.

The view state manager 114 also maintains data (e.g., via a set ofBoolean flags) comprising additional information regarding the currentinteractive state of the view. More particularly, the UI elements(views) additionally support a number of ViewState flags 118, including,but not limited to:

-   -   Focused—The view is focused within its input scope    -   Hovered—The view has pointer input directly over it    -   Listening—The view is listening for command input such as voice        input    -   Selected—The view is active/invoked/toggled on    -   Pressed—The view has either a pointer captured, or has the        invoke button pressed.

Unlike the (mutually exclusive) presence states described above, morethan one of these flags may be set at once, e.g., they may overlap as inFIG. 4. For example, one UI element (view) may be Hovered (because themouse cursor is over it) but not Pressed, whereas another view may beFocused and Pressed.

Like the presence states above, these view states may be styled withtransitions describing the desired state of the UI element when thatflag is true. For example, once a view comprising a menu item is onscreen, the UI developer may want the text color to be green when theitem is listening for voice input (overriding whatever text color themenu uses by default). Similarly, the UI developer may want toreposition an element slightly to the right when it is Hovered orFocused (the style specifies an X offset of some margin), and to movedown slightly when Pressed (the style specifies a Y offset of somemargin). Note however that transitions styled for the view's currentview state flags are applied (in order), whereby some of the transitionsdefined by earlier steps may be overwritten; e.g., the Focused style mayspecify blue font text, while the Pressed style may specify red fonttext, whereby if the Focus styleable transition is applied earlier inthe order than the Pressed styleable transition, red text overwrites theblue text setting when both Focused and Pressed.

It should be noted that “transitions” may be, but need not be, animated.In the above example, the red font text for the Pressed style may simplybe used as is, that is, changed right away without any animatedtransitioning from another color over time; (color changes may beanimated if desired, though).

Also note that only changed/currently relevant information needs to beprocessed by the view state manager. For example, only the ViewStateflags may be accessed and processed if the view state manager alreadyhas any child style override data for the child's parent container.

FIGS. 5A-5F are example representations of animated movement of anelement (child view) entering and exiting a parent view 552 at various“snapshot” times. As is represented, the child view 550 b is originallyin the connected state (FIG. 5A), and transitions to the entering state,which has a stylized transition that includes animating the child view550 c into the scene from left to right (FIGS. 5B and 5C). Animationcontinues, until the child view 550 c settles into a centered “Entered”position (FIG. 5D), which as set forth above may be still considered tobe in the entering presence state. Note that a “Logo” image element orthe like appears in a fixed position in the parent view 552 to emphasizethat the element 550 c is moving over the snapshotted frames of FIGS.5A-5C and 5E, and it is not the parent view 552 that the user perceivesas moving.

Upon some event, the child view 550 c changes to the exiting state(child view 550 d), moving out of the scene to the right as representedin FIG. 5E. For example, the parent view 552 may be changed to a newpage view 554 as in FIG. 5F, causing the exiting transition as well asthe transition to the disconnected state for that parent view 552, andthus the child view 550 a.

Whenever the state of the UI element changes, the view state manager 114re-computes which transitions apply. The view begins with thosetransitions described by its presence, which may then be overridden bythe parent view (e.g., if this view is part of a container that wantsits children to transition on and off screen in some coordinated way).The transition set may be further overridden (or augmented) by any viewstate flags that are set.

When recalculating the set of transitions that apply to a view's currentstate, the view state manager 114 begins with those transitions styledfor the view's current presence. Then, transitions styled for the view'scurrent view state flags are applied (in order), potentially overwritingsome of the transitions defined by earlier actions. The resulting set oftransitions are then turned into animations, e.g., as represented byblock 122 of FIG. 1; if the current values are not the same as thedesired values, the animations to transition from the current values tothe desired values are initiated. Rendering data 124 (including anyanimation data) is used by a rendering mechanism (e.g., a code/logicportion) 126 of the view, whereby the view renders itself, including anyanimation over time. Note that as used herein, “render” in any of itstenses or variants (e.g., rendered, rendering) in addition to visibleoutput may include audio output, tactile output and virtually any otheroutput that can be sensed by a user.

FIGS. 6A and 6B show an example of the hover flag operation. In FIG. 6A,a mouse cursor 660 a (appearing as an arrow-shaped pointer) is nothovering over any of the child view elements 661-664 (children of aparent view, container 665). In FIG. 6B, the mouse cursor 660 b (alsochanged in appearance to a pointing finger) is moved and now hovers overthe child element 662. The child element 662 hovered state results in achange to the ViewState flags (with the hover flag set) processed by theview state manager 114, which then uses a stylized transition for hover(e.g., provided by the child element 662 or possibly as overridden bythe parent container 665). In this example, the child element'sappearance is changed as specified, e.g., an outlined rectanglerepresents the hovered-over element in FIG. 6B instead of a singlenon-outlined rectangle as in FIG. 6A.

FIGS. 7A and 7B show how the focus flag may use transitions andanimation to change an element's appearance, in this example, item 2 anditem 3. In FIG. 7A, the focus flag shifts item 2 to the right, e.g.,because its transition (or its parent's override) specifies an“indented” X offset when focused. In FIG. 7B, item 3 gains focus,whereby item 2 is shifted back to X offset zero and item 3 is shiftedright “based on the indented” X offset. Note that the animations may becoordinated/merged so as to appear to be simultaneous, althoughalternatively the animations may be serially performed.

FIG. 8A shows an example of a menu item 3 that is on screen, Focused,and Pressed. Based on these flags, the view state manager 114 first setsits desired X and Y coordinates and offsets to position the menu item ata correct starting location (the dashed rectangle above and to the leftof item 3), because it is on screen; (in this case, the offsets arefirst zero so as to be on screen in its normal position). As a menuitem, its parent view (the menu) may have additional transitions toapply, such as staggering how the child menu item came onto the screen;(however consider that in this example such additional transitions donot apply). Because it is focused, the desired X offset is overridden tomove right by some margin (FIG. 8A), and because it is pressed, thedesired Y offset is overridden to be down by some margin.

A set of animations is then constructed to transition the menu item fromits current values to the new desired values. In this case, the UIelement for item 3 will move to the right and down, until it has reachedits desired position. The animation may be serial (animate in the Xdirection then in the Y direction) but typically is coordinated (withsome X and Y movement per frame or the like) so as to be perceived assimultaneous.

When that view state changes, for example, if the Pressed flag stopsbeing true, the set of transitions is recalculated. In this case, theresult generally appears as in FIG. 8B, because the Y offset is notoverridden, so it returns to (or remains at) zero. Assuming the menuitem had finished its previous transitions before this change occurred,the X offset transition does not result in an animation (because themenu item already has the desired X offset), but there is a transitioncreated to return the menu item to a Y offset of zero.

FIG. 8C shows how item 3 transitions back when item 3 had focus but thenitem 4 receives focus and is pressed, e.g., the user clicks on item 4.In this example, item 3 reverts to zero X offset, and item 4 transitionsto a new X and Y offset to move item 4 right and down to indicate thefocused, pressed view state.

As can be seen, the result is that as focus moves to and from the menuitem, it smoothly transitions left and right to indicate the focus.Similarly, as the user presses down on the menu item, it will move downand back up again when the button is released. These two transitions canbe styled independently, and may be merged together to determine whichanimations need to apply to make the UI element animate correctly forits current state of presence and view state flags.

FIG. 9 is a flow diagram showing example steps that may be taken by aview with respect to a presence state change and/or a view state change.Step 902 represents receiving an event that triggers the change. As isunderstood, this may be a parent view calling the child view to changeits presence state to entering or to exiting. Another event may berelated to a set of one or more view state changes, e.g., Focused,Hovered, Listening, Selected, and/or Pressed.

Step 904 evaluates whether the change is a presence state change. If so,at step 906 the view state manager knows the type of state change anduses any transition data for the state change. As described herein, someor all of the transition data may be overridden by a parent view.

Step 908 evaluates whether the change is a view state change. If so, atstep 910 the view state manager sets and clears the various ViewStateflags appropriately for the view state change, and determines/uses thetransitions data for the view state change. Note that a state changesuch as losing focus may clear the corresponding ViewState flag, andthus the view state manager may act when any flag changes.

Step 912 represents using the rendering data (including any animationdata) related to the presence change and/or view state change, e.g.,when the view state manager has finished its processing. Step 914represents rendering the view accordingly, including using any animationover an appropriate number of rendering frames.

FIGS. 10 and 11 comprise a flow diagram showing example steps as to howthe view state manager may operate in conjunction with the viewrendering mechanism to provide styleable transitions as describedherein. Step 1002 represents accessing relevant information, which mayinclude state data, transitions, ViewState flags data, and/or childstyle overrides. Note that if any information is needed, the view statemanager may request it, e.g., the parent may be contacted for overridedata (if not already inherited).

Step 1004 represents evaluating whether the presence state has changed.If so, step 1006 applies any transitions associated with the presencestate, e.g., if the view indicates that the state is now exiting, thetransitions associated with the exiting state for that view may be used.Any of these transitions may be overwritten by parent view overrides, asrepresented at step 1008.

Flags are then evaluated in order, beginning at step 1010 for thefocused flag, with step 1012 executed if set. Note that there may not beany flags set yet, e.g., if only transitioning the presence state andits associated transitions. Steps 1014 and 1016 operate similarly forhover.

FIG. 11 continues the flag evaluation via steps 1102 and 1104(listening), steps 1106 and 1108 (selected) and step 1110 and 1112(pressed). Each transition may overwrite the transitions that appliedvia a previously set flag. As can be readily appreciated, the steps ofFIGS. 10 and 11 provide only one example way to handle state changes.For instance, the flag evaluation order may be changed if a differentprecedence is desired; additional flags for other ViewStates may be used(e.g., a “watching” state when awaiting gesture input); and not allflags need to be available in a given scenario.

Step 1114 represents computing and merging any animations that areassociated with the transitions. Step 1116 represents communicatingrendering data to the view rendering mechanism with any animation data,whereby the view renders itself accordingly.

As can be seen, transitions styles describe how a view should enter andexit the scene as well as describe how a view's children should enterand exit the scene. Transition styles also describe how a view shouldreact to changes in view state (being pressed, hovered, focused, and soforth). Transitions can be styled independently on a view, andtransitions are merged together to determine which animations need to berun.

One or more aspects are directed towards changing a view from aconnected state to an entering state, in which the connected statecorresponds to the view being in a view tree and not in a scene, and theentering state corresponds to the view being moved at least partly intothe scene. One or more transitions associated with the entering stateare determined, and used to determine the appearance of the viewentering the scene.

Determining the one or more transitions associated with the enteringstate may comprise using one or more override styles associated with aparent of the view. At least one override style of the parent of theview may be overridden with an override style of a higher-level parentof the parent.

Using the one or more transitions to determine the appearance of theview in the scene may comprise using animation data to move the viewinto the scene over a plurality of rendering frames. Using the one ormore transitions to determine the appearance of the view in the scenemay comprise using at least one transition to vary color, size,position, orientation or opacity.

Upon detecting a change to a view state, one or more view statetransitions associated with the view state change may be determined andused to modify the appearance of the view in the scene to represent theview state change. This may include animating the view to represent theview state change. Determining the one or more view state transitionsassociated with the view state may include obtaining informationindicating that the view state corresponds to one or more of: a hoveredview state, a focused view state, a listening view state, a pressed viewstate, or a selected view state. If there are at least two view statetransitions, using the view state transitions to modify the appearanceof the view may include applying the transitions in a precedence order,

Also described is changing the view from the entering state to anexiting state, which may include determining one or more exitingtransitions associated with the exiting state and using the one or moreexiting transitions to determine the appearance of the view exiting thescene. Using the one or more exiting transitions to determine theappearance of the view exiting the scene comprises animating the view tomove the view out of the scene. The view may be changed from the exitingstate to a disconnected state in which the view is not part of a viewtree. Alternatively, the view may be reverted from the exiting state toanother instance of the entering state.

One or more aspects are directed towards a view associated with acurrent presence state of a set of possible presence states, in whichthe current presence state is associated with one or more transitions. Aview state manager determines rendering data for the current presencestate based at least in part on the one or more transitions associatedtherewith. The view state manager is coupled to (e.g., internallyincorporated into or as an external communicating component) the view touse the rendering data to modify a presentation of the view to a userthat is based upon the current presence state. The current presencestate may comprises an entering state, and the rendering data mayinclude animation data that is used to transition the view over aplurality of rendering frames into a scene.

Interaction with the view may correspond to a view state change, (e.g.,a hovered view state, a focused view state, a listening view state, apressed view state, and/or a selected view state), and if so, the viewstate manager determines view state rendering data based upon the viewstate change, including one or more view state transitions associatedtherewith. The view state manager is coupled to a view renderingmechanism to use the view state rendering data to modify a presentationof the view. The view state transition may cause an animated visualchange to the view to represent the view state change.

One or more aspects are directed towards using one or more styleabletransitions to enter a view into a scene, including animating entry ofthe view into the scene. Upon detecting a view state change, one or morestyleable transitions are used to change the appearance of the viewbased upon the view state change, including animating the appearance ofthe view to indicate the view state change. One or more styleabletransitions are used to exit the view from the scene, includinganimating the exiting of the view from the scene. Using the one or morestyleable transitions to enter the view into the scene may includeoverriding a styleable transition associated with the view with astyleable transition associated with a parent of the view.

Example Computing Device

The techniques described herein can be applied to any device or set ofdevices (machines) capable of running programs and processes. It can beunderstood, therefore, that personal computers, laptops, handheld,portable and other computing devices and computing objects of all kindsincluding cell phones, tablet/slate computers, gaming/entertainmentconsoles and the like are contemplated for use in connection withvarious implementations including those exemplified herein. Accordingly,the general purpose computing mechanism described below in FIG. 11 isbut one example of a computing device.

Implementations can partly be implemented via an operating system, foruse by a developer of services for a device or object, and/or includedwithin application software that operates to perform one or morefunctional aspects of the various implementations described herein.Software may be described in the general context of computer executableinstructions, such as program modules, being executed by one or morecomputers, such as client workstations, servers or other devices. Thoseskilled in the art will appreciate that computer systems have a varietyof configurations and protocols that can be used to communicate data,and thus, no particular configuration or protocol is consideredlimiting.

FIG. 11 thus illustrates an example of a suitable computing systemenvironment 1100 in which one or aspects of the implementationsdescribed herein can be implemented, although as made clear above, thecomputing system environment 1100 is only one example of a suitablecomputing environment and is not intended to suggest any limitation asto scope of use or functionality. In addition, the computing systemenvironment 1100 is not intended to be interpreted as having anydependency relating to any one or combination of components illustratedin the example computing system environment 1100.

With reference to FIG. 11, an example device for implementing one ormore implementations includes a general purpose computing device in theform of a computer 1110. Components of computer 1110 may include, butare not limited to, a processing unit 1120, a system memory 1130, and asystem bus 1122 that couples various system components including thesystem memory to the processing unit 1120.

Computer 1110 typically includes a variety of machine (e.g., computer)readable media and can be any available media that can be accessed by amachine such as the computer 1110. The system memory 1130 may includecomputer storage media in the form of volatile and/or nonvolatile memorysuch as read only memory (ROM) and/or random access memory (RAM), andhard drive media, optical storage media, flash media, and so forth. Byway of example, and not limitation, system memory 1130 may also includean operating system, application programs, other program modules, andprogram data.

A user can enter commands and information into the computer 1110 throughone or more input devices 1140. A monitor or other type of displaydevice is also connected to the system bus 1122 via an interface, suchas output interface 1150. In addition to a monitor, computers can alsoinclude other peripheral output devices such as speakers and a printer,which may be connected through output interface 1150.

The computer 1110 may operate in a networked or distributed environmentusing logical connections to one or more other remote computers, such asremote computer 1170. The remote computer 1170 may be a personalcomputer, a server, a router, a network PC, a peer device or othercommon network node, or any other remote media consumption ortransmission device, and may include any or all of the elementsdescribed above relative to the computer 1110. The logical connectionsdepicted in FIG. 11 include a network 1172, such as a local area network(LAN) or a wide area network (WAN), but may also include othernetworks/buses. Such networking environments are commonplace in homes,offices, enterprise-wide computer networks, intranets and the Internet.

As mentioned above, while example implementations have been described inconnection with various computing devices and network architectures, theunderlying concepts may be applied to any network system and anycomputing device or system in which it is desirable to implement suchtechnology.

Also, there are multiple ways to implement the same or similarfunctionality, e.g., an appropriate API, tool kit, driver code,operating system, control, standalone or downloadable software object,etc., which enables applications and services to take advantage of thetechniques provided herein. Thus, implementations herein arecontemplated from the standpoint of an API (or other software object),as well as from a software or hardware object that implements one ormore implementations as described herein. Thus, various implementationsdescribed herein can have aspects that are wholly in hardware, partly inhardware and partly in software, as well as wholly in software.

The word “example” is used herein to mean serving as an example,instance, or illustration. For the avoidance of doubt, the subjectmatter disclosed herein is not limited by such examples. In addition,any aspect or design described herein as “example” is not necessarily tobe construed as preferred or advantageous over other aspects or designs,nor is it meant to preclude equivalent example structures and techniquesknown to those of ordinary skill in the art. Furthermore, to the extentthat the terms “includes,” “has,” “contains,” and other similar wordsare used, for the avoidance of doubt, such terms are intended to beinclusive in a manner similar to the term “comprising” as an opentransition word without precluding any additional or other elements whenemployed in a claim.

As mentioned, the various techniques described herein may be implementedin connection with hardware or software or, where appropriate, with acombination of both. As used herein, the terms “component,” “module,”“system” and the like are likewise intended to refer to acomputer-related entity, either hardware, a combination of hardware andsoftware, software, or software in execution. For example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration, both an application runningon a computer and the computer can be a component. One or morecomponents may reside within a process and/or thread of execution and acomponent may be localized on one computer and/or distributed betweentwo or more computers.

The aforementioned systems have been described with respect tointeraction between several components. It can be appreciated that suchsystems and components can include those components or specifiedsub-components, some of the specified components or sub-components,and/or additional components, and according to various permutations andcombinations of the foregoing. Sub-components can also be implemented ascomponents communicatively coupled to other components rather thanincluded within parent components (hierarchical). Additionally, it canbe noted that one or more components may be combined into a singlecomponent providing aggregate functionality or divided into severalseparate sub-components, and that any one or more middle layers, such asa management layer, may be provided to communicatively couple to suchsub-components in order to provide integrated functionality. Anycomponents described herein may also interact with one or more othercomponents not specifically described herein but generally known bythose of skill in the art.

In view of the example systems described herein, methodologies that maybe implemented in accordance with the described subject matter can alsobe appreciated with reference to the flowcharts/flow diagrams of thevarious figures. While for purposes of simplicity of explanation, themethodologies are shown and described as a series of blocks, it is to beunderstood and appreciated that the various implementations are notlimited by the order of the blocks, as some blocks may occur indifferent orders and/or concurrently with other blocks from what isdepicted and described herein. Where non-sequential, or branched, flowis illustrated via flowcharts/flow diagrams, it can be appreciated thatvarious other branches, flow paths, and orders of the blocks, may beimplemented which achieve the same or a similar result. Moreover, someillustrated blocks are optional in implementing the methodologiesdescribed herein.

CONCLUSION

While the invention is susceptible to various modifications andalternative constructions, certain illustrated implementations thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

In addition to the various implementations described herein, it is to beunderstood that other similar implementations can be used ormodifications and additions can be made to the describedimplementation(s) for performing the same or equivalent function of thecorresponding implementation(s) without deviating therefrom. Stillfurther, multiple processing chips or multiple devices can share theperformance of one or more functions described herein, and similarly,storage can be effected across a plurality of devices. Accordingly, theinvention is not to be limited to any single implementation, but ratheris to be construed in breadth, spirit and scope in accordance with theappended claims.

What is claimed is:
 1. A method comprising: changing a view from aconnected state to an entering state, in which the connected statecorresponds to the view being in a view tree and not in a scene, and theentering state corresponds to the view being moved at least partly intothe scene; determining one or more transitions associated with theentering state; and using the one or more transitions to determine theappearance of the view entering the scene.
 2. The method of claim 1wherein using the one or more transitions to determine the appearance ofthe view in the scene comprises using animation data to move the viewinto the scene over a plurality of rendering frames.
 3. The method ofclaim 1 wherein using the one or more transitions to determine theappearance of the view in the scene comprises using at least onetransition to vary color, size, position, orientation or opacity.
 4. Themethod of claim 1 further comprising, detecting a change to a viewstate, determining one or more view state transitions associated withthe view state change, and using the one or more view state transitionsto modify the appearance of the view in the scene to represent the viewstate change.
 5. The method of claim 4 wherein using the one or moreview state transitions to modify the appearance of the view in the sceneincludes animating the view to represent the view state change.
 6. Themethod of claim 4 wherein determining the one or more view statetransitions associated with the view state comprises obtaininginformation indicating that the view state corresponds to one or moreof: a hovered view state, a focused view state, a listening view state,a pressed view state, or a selected view state.
 7. The method of claim 4wherein the view state change corresponds to at least two view statetransitions, and wherein using the view state transitions to modify theappearance of the view comprises applying the transitions in aprecedence order.
 8. The method of claim 1 wherein determining the oneor more transitions associated with the entering state comprises usingone or more override styles associated with a parent of the view.
 9. Themethod of claim 1 wherein determining the one or more transitionsassociated with the entering state comprises using one or more overridestyles associated with a parent of the view, and overriding at least oneoverride style of the parent of the view with an override style of ahigher-level parent of the parent.
 10. The method of claim 1 furthercomprising, changing the view from the entering state to an exitingstate, including determining one or more exiting transitions associatedwith the exiting state and using the one or more exiting transitions todetermine the appearance of the view exiting the scene.
 11. The methodof claim 10 wherein using the one or more exiting transitions todetermine the appearance of the view exiting the scene comprisesanimating the view to move the view out of the scene.
 12. The method ofclaim 10 further comprising, changing the view from the exiting state toa disconnected state in which the view is not part of a view tree. 13.The method of claim 10 further comprising, reverting the view from theexiting state to another instance of the entering state.
 14. A systemcomprising: a view, the view associated with a current presence state ofa set of possible presence states, the current presence state associatedwith one or more transitions; and a view state manager, the view statemanager configured to determine rendering data for the current presencestate based at least in part on the one or more transitions associatedtherewith, the view state manager coupled to the view to use therendering data to modify a presentation of the view to a user that isbased upon the current presence state.
 15. The system of claim 14wherein the current presence state comprises an entering state, andwherein the rendering data includes animation data that is used totransition the view over a plurality of rendering frames into a scene.16. The system of claim 14 wherein interaction with the view correspondsto a view state change, and wherein the view state manager is furtherconfigured to determine view state rendering data based upon the viewstate change including one or more view state transitions associatedtherewith, the view state manager coupled to a rendering mechanism ofthe view to use the view state rendering data to modify a presentationof the view.
 17. The system of claim 14 wherein the view statetransition causes an animated visual change to the view to represent theview state change.
 18. The system of claim 14 wherein the view statechange corresponds to one or more of: a hovered view state, a focusedview state, a listening view state, a pressed view state, or a selectedview state.
 19. One or more machine-readable storage media havingmachine-executable instructions, which when executed perform steps,comprising: using one or more styleable transitions to enter a view intoa scene, including animating entry of the view into the scene; detectinga view state change; using one or more styleable transitions to changethe appearance of the view based upon the view state change, includinganimating the appearance of the view to indicate the view state change;and using one or more styleable transitions to exit the view from thescene, including animating the exiting of the view from the scene. 20.The one or more machine-readable storage media of claim 19 wherein usingthe one or more styleable transitions to enter the view into the scene,comprises overriding a styleable transition associated with the viewwith a styleable transition associated with a parent of the view.